Previous Book Contents Book Index Next

Inside Macintosh: Open Transport /
Chapter 1 - Introduction to Open Transport

About Networking With Open Transport

Networking on the Macintosh is implemented through the Open Transport system software. The Open Transport software provides an API that gives you access to the services of the various protocols. The functions you use depend not on the specific protocol you want to use, but on whether the protocol is connection-oriented or connectionless, and whether it is transaction-based or transactionless.

This section describes the architecture of Open Transport and discusses some basic Open Transport features and concepts.

Open Transport Architecture

The Open Transport system software consists of a set of application interface and utility routines (known collectively as the Open Transport API), a set of software modules that implement networking protocols and other services, and hardware drivers. Below the hardware drivers are networking and communications hardware: cards, cables, and built-in ports. These components are illustrated in Figure 1-2 and discussed further in the following sections.

Figure 1-2 The basic architecture of Open Transport

Open Transport API

The Open Transport API consists of two types of functions: utility functions, which are implemented in header files and software libraries; and interface functions, which are implemented by the underlying software modules. Because the interface functions are executed by the software modules, the same function might operate somewhat differently depending on the specific module or modules that executes it. Where such dependencies exist, they are described in the chapter describing a particular protocol.

The Open Transport API is a superset of a standard API defined by the X/Open Company, Ltd. The X/Open API is called the X/Open Transport Interface, or XTI. Both XTI and Open Transport are designed to be independent of the underlying data transport provider; for example, you use the same functions to send a packet of data whether the packet is being transferred by DDP over an AppleTalk network or IP over Ethernet. Whereas XTI specifies functions only for connectionless and connection-oriented protocols, Open Transport also includes functions for transactionless and transaction-based protocols.

The set of functions you use and the sequence of functions you call depends on the operation you want to perform and whether the protocol you want to use is connectionless or connection-oriented, transactionless or transaction-based.

In accordance with XTI, the Open Transport API supports protocol options. An option is a value of interest to a specific protocol. For example, an option might enable or disable checksums or specify the priority of a datagram. The available options and their significance are defined by each implementation of each protocol. Every option has a default value, and you can almost always use the default values and not specify any options. It is important to note that, because each option is protocol dependent, specifying a nondefault value for an option decreases or eliminates the transport independence of your application. Protocol options are described throughout this book with the protocol to which they apply. Option handling is described in the chapter "Option Management" in this book.

The XTI specification defines a number of asynchronous events that indicate occurrences such as the arrival of data. Open Transport includes all the standard events defined by XTI, additional asynchronous events, plus completion events that individual functions issue when they complete asynchronous execution. You can poll for asynchronous events, but you cannot poll for completion events. The preferred method for handling all Open Transport events is to write an event-handling callback function, called a notifier function. Open Transport event handling and notifier functions are described in detail in the chapter "Providers" in this book.

Software Modules

The software modules shown in Figure 1-2 on page 1-11 are implemented as Streams modules. The Streams architecture is a UNIX® standard in which protocols (and other service providers) are implemented as software modules that communicate between each other using messages. Open Transport conforms to the Transport Provider Interface (TPI) and Data Link Provider Interface (DLPI) standards, which describe the content and ordering of the messages between modules. In a Streams environment, all modules have the following attributes:

Note that Figure 1-2 on page 1-11 shows a very simplified version of the actual Streams architecture. A full AppleTalk or TCP/IP protocol stack has a half-dozen modules that are interconnected.

You can write your own Streams modules to work with Open Transport. The Open Transport TCP/IP software modules are based on the UNIX Streams standard. For more information about Streams, see UNIX System V Release 4: Programmer's Guide: STREAMS.

Drivers and Hardware

The Open Transport Streams modules communicate with hardware drivers, which in turn control the flow of data through communications cards or built-in ports. Normally, the user selects which card or port to use through the Chooser. Your application can use the default port for a particular protocol or can configure Open Transport to use a specific port.

Open Transport supports multihoming; that is, an individual node can have more than one hardware device (ports or cards) for a given type of transport. For example, a single computer can have two Ethernet cards, and the user can select which card to use.

Providers, Endpoints, and Mappers

The concept of a provider is central to an understanding of Open Transport. A provider is a set of software modules and drivers that provides a service to clients of Open Transport. For example, when you open an ADSP connection, Open Transport logically links a set of AppleTalk software modules, a communications driver, and a card or port to create what is known as an ADSP endpoint provider. The Open Transport software modules implement the Open Transport API, which includes functions for three types of providers:

You use an endpoint provider to send and receive information over a data link. Figure 1-3 illustrates an ASP endpoint provider.

Figure 1-3 An Open Transport Provider

In order to use an endpoint provider, you must first configure and open an endpoint. An endpoint consists of a set of data structures, maintained by Open Transport, that specify the components of the endpoint provider, and the manner in which that provider is to operate (blocking or nonblocking, synchronous or asynchronous, and so forth). An endpoint also maintains state information and other information that Open Transport needs in order to operate that provider.

The Open Transport endpoint functions provide an application programming interface (API) to endpoint providers. When you configure an Open Transport endpoint, you specify which protocol or set of protocols the provider is to use; the highest-level protocol you specify for the endpoint provider determines whether the transport mechanism is connectionless or connection-oriented, and whether it is transactionless or transaction-based. For example, if you specify ADSP as the highest-level protocol in the endpoint provider, the transport is connection-oriented and transactionless.

See "Endpoints and Protocol Layering" on page 1-17 for more information on the configuration of endpoint providers.

You use a mapper provider to relate network addresses to network node names and to register and remove node names for networks that support this ability. To use a mapper provider, you must configure and open a mapper, a set of data structures that store information about the mapper provider for use by Open Transport.

Mappers implement a standard interface for dealing with addresses. In order to receive data over a network, a process must have a network address. Whereas an address is typically a number of significance to the network software, it is much easier for people using the network to refer to each addressable entity by some name. Consequently, most networks include some naming scheme and a facility that converts between names and addresses. A process using an AppleTalk network must register its name on the network using the Name-Binding Protocol (NBP), which it accesses through a mapper provider.

You use service providers to handle features unique to a specific type of Open Transport service. There is no special term used to refer to the data structures maintained by Open Transport for a service provider analogous to an endpoint or mapper.

Because the concept of zones is not common to all protocol families, the AppleTalk service provider API includes functions that deal with AppleTalk zones. Similarly, the TCP/IP Domain Service Resolver (DNR) provides some services specific to the TCP/IP protocol family. The TCP/IP service provider functions provide an interface to the DNR.

Each provider supports some subset of the standard Open Transport functions, depending on the nature of that provider; for example, an endpoint provider implements different functions than a mapper provider. What's more, a connection-oriented transactionless endpoint provider implements different functions than a connectionless transaction-based endpoint provider.

Open Transport provides some functions that you can use to control the way a given endpoint or mapper provider operates. For example, you can control whether a provider executes functions synchronously or asynchronously.

When you open an endpoint, mapper, or service , the open function returns a provider reference, analogous to the file reference you get from the File Manager when you open a file. You must specify that provider reference whenever you want to execute a function related to that endpoint, mapper, or service. For example, to send data, you specify the provider reference for the endpoint you want to use.

C++ note

The C++ API for Open Transport includes a class called TProvider that is the superclass for all provider-related member functions. Endpoint functions are in class TEndpoint, mapper functions are in class TMapper, and service provider functions are in classes corresponding to specific protocol stacks. For example, the classes TAppleTalkServices and TInternetServices contain AppleTalk-specific and TCP/IP-specific member functions.
In object-oriented programming parlance, endpoints, mappers, and the data structures maintained by Open Transport for service providers are all objects. An endpoint, for example, is an object instantiating the class TEndpoint. An endpoint contains all the data that Open Transport needs to link together software modules, drivers, and hardware for a specific endpoint provider. All of the Open Transport API functions except the functions that open providers and some utility functions are included in the class definitions of the various classes of providers.
You can call public member functions of the TProvider class for provider objects of any type: these functions are the general provider functions. Public member functions defined in a subclass of the TProvider class (for example, TEndpoint) can be called only for providers belonging to that subclass--in this example, only from the TEndpoint subclass. These functions are the type-specific provider functions. Note that, like endpoints and mappers, each kind of service (for AppleTalk, TCP/IP, and so on) derives directly from the TProvider class; there is no common class of services.

Transport Independence

In contrast to earlier application programming interfaces (APIs) for AppleTalk, in which each protocol had a separate and unique set of routines, Open Transport provides a single set of functions that you can use with any protocol or protocol family. The type of endpoint you open (connectionless or connection-oriented, and transactionless or transaction-based) determines which functions you call to send and receive data, independent of the specific protocol or protocol family you use.

For example, if you open a connectionless, transactionless endpoint, you use the OTSndUData function to send data. You use this function whether you are using DDP, IP, or UDP. If you open a connection-oriented, transactionless endpoint, on the other hand, you first establish a connection using the OTConnect and OTRcvConnect functions, and then use the OTSnd function to send data. You use these same functions whether you are using TCP, ADSP, or any other Open Transport connection-oriented, transactionless protocol.

You can customize most Open Transport protocols by the specification of option values. Because options are both protocol dependent and implementation dependent, the use of any option values other than the defaults makes your code less transport independent and less portable. Unless you have a compelling reason to change an option value, don't specify any options. You can almost always use the default values provided by Open Transport.

Although transport independence means that you can use the same API regardless of the protocol or communcations hardware you want to use, it does not free you from all knowledge of the transport type. When you open an endpoint, you must specify the highest-level protocol in the endpoint provider, and you must call the functions appropriate to the type of that protocol. For example, although your application can use the same set of functions to send data through either an ADSP or a TCP connection (that is, functions for a connection-based transactionless protocol), you must specify which of these protocols you want to use use when you open the endpoint. Furthermore, to send data using ASP, you must use a different set of functions--for a connection-oriented transaction-based protocol.

Endpoints and Protocol Layering

When you configure an Open Transport endpoint, you specify the highest-level protocol to be used by that endpoint provider. Optionally, you can specify other protocols and ports to be included in the endpoint provider. For example, if you specify only ADSP, Open Transport uses the default underlying protocol for ADSP, which is DDP, over the default AppleTalk port. However, you can specify that ADSP is to use a specific Ethernet card as the port. The endpoint provider consists of the software modules, drivers, and card or internal port that are linked together to provide the service. The services provided by an endpoint provider are an aggregate of the services performed by all the software modules and hardware pieces that make up the provider. For example, if you specify ADSP to run over DDP through an Ethernet card, you get a session opened and maintained by ADSP, with data encapsulated in DDP packets, converted into digital electronic impulses by the Ethernet card, and transmitted to a DDP address over an Ethernet cable.

Because the type of endpoint you open depends only on the highest-level protocol in the endpoint provider, protocol layering does not affect the transport independence of Open Transport. That is, you use the same functions to open and maintain a connection and to send messages whether you are using ADSP over DDP through Ethernet, or TCP over IP through token ring.

Previous Book Contents Book Index Next

© Apple Computer, Inc.
15 AUG 1996